Several types of secure elements are known to be used in host devices such as mobile terminals, smartphones, digital tablets, etc.
A first type is known under the name UICC (Universal Integrated Circuit Card), set out in the standard ETSI SP 102 221 and includes conventional smartcards, SIM cards (or USIM—Universal Subscriber Identity Module), as well as security tokens.
A second type, which is of interest for the present invention, is known under the name “embedded secure element” or eSE and set out in the “GlobalPlatform Card Specification Version 2.2.1” standard relative to the GlobalPlatform technology.
These two types of secure elements have internal safety means or mechanisms to ensure the integrity and security of sensitive data and sensitive services that they host.
One essential difference between these two types of secure elements lies in the autonomy that they have to establish a connection with remote equipment, typically an OTA (Over-The-Air) server outside the host device.
The UICC card has master means in establishing such a connection. In other words, an application of the UICC card may take the initiative to create such an establishment, for example using available capacities in the host device (for example the SIM ToolKits tools). The UICC card is said to be a “connected” secure element.
A UICC card can, at its own initiative, send an SMS message to an OTA server to initiate such a connection. By way of example, publication EP 2,453,377 describes a UICC whereof an administrator can manage an OTA server using an HTTP connection.
The embedded secure element eSE is, meanwhile, a slave element of applications residing on the host device, i.e., a slave in a master-slave relationship in the upper layers of the OSI model, in particular in the application layer (layer 7), or in layers 5 and 6. Thus, establishing a connection with the outside requires an application residing on the host device, which is the only one to take the initiative in the establishment. It is that application that decides to connect the eSE to an external server.
As an example, the eSE can form the secure element necessary for many uses or services based on a NFC (Near Field Communication) implemented by a host mobile terminal. For example, an NFC payment service requires secret banking information from the user that is advantageously stored in the eSE, sheltered from any untimely access.
FIG. 1 illustrates a logic architecture of an eSE 50 and a host device 100 integrating it, according to the GlobalPlatform technology.
The eSE comprises an operating system OSeSE, a main security domain or “issuer” 51, denoted ISD for Issuer Security Domain, and applications App accessible via the ISD 51. Other security domains 52, 53 (supplementary security domains, SSD) with a lower priority than the ISD 51 may also be provided with their applications App.
The ISD 51 is necessary within the eSE to allow administration of the secure element eSE, and in particular management of the other security domains. This for example allows the holder/owner of the ISD 51 to sublet part of the eSE or to share the control thereof with other partners, for example business partners, by installing their own security domains for them.
Since the eSE is a slave device for applications residing on the host device 100 providing an end user with services (App1, App2, App3), the GlobalPlatform technology defines the interface between these resident applications and the eSE. It in particular defines the API (Application Programming Interface) provided in the host device to access the eSE via software controllers (drivers).
Examples of applications App1, App2, App3 include mobile payment applications, transport ticketing applications, access control applications, toll payment applications, etc. It should be noted that mechanisms inside the eSE (in particular the ACF—Access Control Functions) make it possible to associate the resident applications with each security domain of the eSE.
Each security domain holds a set of encryption keys, generally at least three keys, that are used to implement secure communications with the servers of an external infrastructure that also holds those keys or corresponding keys (case of asymmetrical keys), as well as for secure content management in the eSE for those external servers, for example the management of internal keys, encryption/decryption, controlling the ADPU command sequencing, etc. to secure access to data and services internal to the eSE.
Consequently, for each security domain of the eSE, an external infrastructure or entity exists that holds the keys associated with that security domain. These external entities thus provide end users with applications to be installed on the host terminal and that will interact with the eSE to provide services.
The ISD 51 is attached to the sender or holder or owner of the eSE, i.e., generally the manufacturer of the host device 100. The SSDs are attached to the business partners of the manufacturer, i.e., Entity1 and Entity2.
To provide secure management of the eSE, the sender or holder or owner (Issuer) has an application representative within the host device. This representative is implemented by an application agent residing on the host device allowing the establishment between administration servers of the Issuer and the ISD 51 of the eSE. This application agent is referred to as an “administrator agent” or “Admin agent” according to specification “GPD_SPE_008—Secure Element Remote Application Management” and is configured to connect to one or more administration servers managed by the Issuer. It is also commonly referred to as a “Proxy agent”, as it connects (proxy function) these administration servers to the issuer security domain ISD 51 of the eSE. Subsequently, reference will essentially be made to an “Admin/Proxy Agent”.